home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0258.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  4.7 KB  |  100 lines
  1. Nathaniel was kind enough to forward your message to me.
  2.  
  3. > I recall being flamed rather severely by Ned Freed when I suggested
  4. > that MIME was inadequate because the specification of format-types
  5. > such as 'postscript' or 'gif' didn't specify enough about format
  6. > versions, external resources used, etc.
  7.  
  8. The flaming, if you wish to call it that, was caused by what I saw as a
  9. repeated failure on your part to read the words I was writing. I certainly did
  10. not flame you because of this idea. It isn't a bad idea on the surface; it only
  11. falls apart upon close examination.
  12.  
  13. >  Many of his arguments were based on the practical difficulties of
  14. > requiring any kind of additional standardization for document format
  15. > versions in a distributed mail application.
  16.  
  17. My position regarding PostScript is based on three facts:
  18.  
  19. (1) Mechanisms already exist for imbedding all this information inside
  20.     PostScript objects. This format is readily understandable and easy to
  21.     process.
  22.  
  23. (2) Generation of this information if it isn't already in a given object isn't
  24.     just hard, it is totally and completely impossible. It is trivial to
  25.     demonstrate that this is equivalent to the halting problem. The notion
  26.     that something "close" the correct could be generated with a little work is
  27.     highly suspect, as are the advantages of producing external labelling that's
  28.     guaranteed to be inaccurate in some cases.
  29.  
  30. (3) When the external information <> internal information you have a silly
  31.     state. A guiding principle of the working group was to avoid silly
  32.     states whenever possible.
  33.  
  34. Modulo the notion in (2) these are all facts and not opinions. Based on these
  35. facts I think external format labelling of PostScript is an extremely bad idea.
  36.  
  37. I am much less familiar with GIF and I have relied on other folks who are
  38. more expert than I to deal with GIF issues.
  39.  
  40. > Now that MIME is out as a proposal for mail, I still believe that
  41. > these problems should be addressed before MIME is appropriate for
  42. > database, archival and retrieval applications.
  43.  
  44. As far as PostScript goes I think I have made my position clear. It has not
  45. changed in any way since we last communicated. However, my position on
  46. PostScript does not necessarily apply to other formats. Each format is a
  47. separate beast and must be handled in a manner that matches its nature. Just
  48. because I am opposed to external labelling of PostScript doesn't mean external
  49. labelling of something else is inappropriate. It usually boils down to
  50. examination of three issues:
  51.  
  52. (1) Is internal labelling feasible? If feasible do applications actually use it?
  53.  
  54. (2) How hard is it to derive external label information? There are basically
  55.     three possibilities: it is either something you just have to know (like
  56.     the character set), it is always part of the object (like WordPerfect
  57.     version numbers), or it can be produced from analysis of the input.
  58.  
  59. (3) Is there potential for conflict between internal and external labelling?
  60.  
  61. The interactions between these things is complex; I have never derived an
  62. explicit cause-and-effect path from these to whether or not an external
  63. label should be used.
  64.  
  65. > In addition, the current mechanism in MIME for external references suffers the
  66. > same problem that other references mechanisms that are based on
  67. > hostname/pathname have: files move, change in place, host names come and go
  68. > over the years.
  69.  
  70. I certainly agree that this is a problem. I would love to see it solved, and I
  71. would welcome the introduction of additional parameters to solve it.
  72.  
  73. However, I don't see any way to solve it without introducing at least one
  74. additional level of indirection. This means some kind of directory service
  75. would have to be deployed. Now, this may be a good idea, in fact it may be a
  76. terrific idea, but it is somewhat beyond MIME's purview to define a directory
  77. service for locating objects.
  78.  
  79. In other words, I believe the solution to this problem would at a minimum
  80. involve the introduction of some kind of directory service (which could be
  81. accessed via MIME messages but in practice would probably require a direct
  82. protocol connection) and the definition of a new sort of external reference
  83. with parameters appropriate for reaching this service. The difficult parts of
  84. this are the methods you use in the directory to keep existing pointers valid
  85. and the definition of the directory access protocol itself. The extensions to
  86. MIME are the trivial part.
  87.  
  88. I would welcome further discussion on how we should work towards solving
  89. these problems.
  90.  
  91. > Both these problems are not trival to solve, but I don't think they
  92. > are unsolvable.
  93.  
  94. They are extremely difficult problems to solve. However, the first step towards
  95. their solution is to focus on where the problems really are, and I don't think
  96. that's MIME.
  97.  
  98.                 Ned
  99.  
  100.